In a distributed communications environment, resources may be shared among a plurality of the nodes of the distributed environment. In order to coordinate access to the shared resources, a distributed lock manager is used. In one example, the distributed lock manager includes a layer of software that runs on each of the nodes of the environment.
The distributed lock manager uses at least one locking protocol to coordinate access to the shared resources. In one example, the locking protocol is a token-based protocol in which the distributed lock manager interfaces with a token server to obtain tokens, and then grants lock requests based on the granted tokens.
For example, when an application requests a lock of a resource, the local lock manager of the node in which the application is executing sends a request to the token server to acquire a corresponding token for the resource. Once the token is acquired, the lock manager grants the requested lock. When the lock is released, the node retains the token so that subsequent lock requests for the same object can be granted locally without requiring additional messages to the token server. The token server keeps track of which tokens are held by which nodes.
When the token server receives a request from a node for a token that is currently held by another node, the other node needs to relinquish its token before it can be granted to the requesting node. This is accomplished by having the lock manager of the requesting node send a revoke request to the node holding the token. In response to the revoke request, the node checks whether a lock requiring the token is currently held, waits for any such lock to be released, and then sends a message to the token server to relinquish the token.
The token server keeps full state of the tokens for each client. This is described in, for instance, U.S. Pat. No. 5,454,108, entitled “Distributed Lock Manager Using A Passive, State-Full Control-Server”, issued on Sep. 26, 1995, which is hereby incorporated herein by reference in its entirety. Although the server keeps full state for each client, the server has no way to communicate back to the client to control the size of the state that each client consumes. That is, the server is passive in that it will not initiate communication to a client to control the size of the token cache. Thus, the token server can run out of memory. When this happens, the token server stops granting tokens. This is especially problematic for byte range tokens, which are kept in a balanced tree, which consumes a great deal of memory when used even with one very large file.
Thus, a need exists for a token server that takes an active role in monitoring its memory usage. A further need exists for a capability that enables the token server to take action based on that monitoring.